Often events occur in peripheral devices that require the attention of a host processor or CPU. Typically the intervention is provided by a control or service program executing on the host processor. An example of an event is when new data is available for transfer from a peripheral device to a host processor. Another example of an event is when a device is ready to accept new data for transfer from a host processor to the device. These service needs of peripheral devices must be communicated in a timely manner from the peripheral devices to the host processor. A specialized controller is sometimes used to communicate the service needs and may be quite specialized for that particular peripheral device. In addition, the service needs require timely communication between the host processor and the devices.
In the prior art, two basic approaches are known for communicating such service needs or requests from a device to a host processor. The first method is interrupts, wherein the regular sequence of instruction execution of the host processor is interrupted and control is transferred to a device service routine. Interrupts or interrupt requests typically involve dedicated hardware and control signals. The second method is polling, wherein the host processor frequently interrogates each device controller to obtain its current status. The host processor tests this status and then transfers control to a device service routine if required. Polling generally requires software executing on the host to check if a peripheral device has a service need.
One substantial drawback to interrupts is the overhead required to switch contexts between the regular sequence of instruction execution and the execution of an interrupt-driven routine to service the device. Context refers to the present state of registers and memory values that the host is presently operating with. The current values in all, or many, of the host processor's registers and counters are typically saved in main memory before control is transferred to the device service routine, thereby saving the present context before servicing an interrupt. In addition, these saved values are restored to the registers after the device service routine finishes and before control returns to point in the regular sequence of instructions where it was interrupted, thereby restoring the original context. Alternatively, a second set of hardware registers dedicated solely to interrupt service may be implemented. Either alternative requires additional hardware costs and complexity. Processor execution time is degraded by having to save the host context and then return to that context to proceed with further operations.
Another disadvantage to interrupts is the overhead that is required to identify which one of various devices requires service of the current interrupt request. It is common for an interrupt-driven service routine to poll, as its first task, the various device controllers it supports to determine which one initiated the current interrupt. One approach to reducing this time and complexity is to encode a vector in the hardware-level interrupt request. This vector specifies which type of interrupt, out of a handful of possible interrupt types or vector values, occurred. In such vectored interrupt systems, the overhead time between the interrupt occurrence and the start of the "useful" portion of the device service routine is reduced. This reduction in processing time occurs at the expense of additional hardware cost and complexity, thus the system architecture typically supports only a handful of possible values of interrupt vectors. In many systems, interrupt vectors are scarce resources that must be wisely allocated to optimize overall system performance. Due the limited number of different vector values, conflicts among various peripheral devices over the use of an interrupt vector are common occurrences when configuring or reconfiguring 286-based or 386-based personal computer systems. The drawbacks of vectored interrupts becomes onerous in data communications applications, where one may need to support 50 to 100 user terminals from a single host processor. Whether or not vectored interrupts are used, host processors that service a large number of communications channels must spend a significant fraction of their processor resources (e.g. CPU time) entering and exiting interrupt-driven device service routines, if support of the communications channels is solely through interrupts.
In contrast to the interrupt approach, some host processors poll the devices they support, i.e. they interrogate each of the device controller(s) they support to obtain the current status of the device(s) that the particular controller supports. The polling approach eliminates the host processor time required to enter and exit interrupt service routines and the hardware required to support interrupts. Nevertheless, polling typically requires that a significant, and possibly a very substantial, portion of the host processor time be spent polling, i.e. performing these interrogations and the associated tests of the status information obtained to see if any device requires service. In order to respond promptly to service requests when they do occur, the host processor must frequently interrogate each device controller such that it is unlikely that any particular interrogation reveals a service request.
Servicing the needs of peripheral devices also requires that appropriate priorities be established. For example, if a host processor supports a disk and a keyboard, then a delay of 100 ms in servicing an interrupt from the keyboard is likely to be imperceptible. However, a delay of 10 ms in servicing an interrupt from a disk may have an adverse effect such that the disk's continued rotation during the service delay has left the disk and read/write head mis-positioned for the present action requesting the interrupt or the next action. Appropriate prioritization of device service requests increases the hardware cost and complexity and/or increases the host processor time requirements. This applies both to interrupt-based and to polled architectures.
In the prior art, a major challenge for a computer system designer was to somehow transform a steady but unpredictable stream of service requests from a multitude of devices into something that the host processor can manage and control economically. FIG. 1 shows a prior-art solution to the device-service problem. One or more interrupt request lines from peripheral device(s) were connected to a hardware device called an interrupt controller. The interrupt controller could possibly consist of discrete logic or a separate monolithic integrated circuit. Interrupt controllers typically have the capacity to receive a handful of individual interrupt request inputs from peripheral devices. The interrupt request inputs are prioritized among potentially simultaneous requests according to some algorithm that is fixed within the controller hardware. In response to the assertion of an interrupt request, the controller asserts a master interrupt request signal to its host processor. On receipt of an interrupt acknowledgment signal from the host processor, the controller asserts an interrupt acknowledge signal to the specific peripheral device which is being acknowledged. The peripheral device responds to the acknowledgment by placing an interrupt vector on the data bus. The interrupt vector generally contained information of which peripheral or group of peripherals made the request so that the host knew which device to talk to. Depending on the function and sophistication of the peripheral device, the peripheral device (it) may enter a specific interrupt "context" or state to facilitate the performance by the host processor of the task that required service. To improve the process of a stream of interrupt requests from the same device, queues were introduced. A queue is a method of stacking many requests on top of one another. Thus the host processor can process a queued stack of interrupts from the same device or ensemble of devices. Since these am usually similar types of interrupts the host processor stays in the same context. Thus the efficiency of the interrupt handling is improved.
FIG. 2 shows another prior-art solution to improve the performance of handling interrupt requests. Using some discrete or "glue" logic in addition to interrupt control hardware, the interrupt request lines from the peripheral controller are OR'ed together and the result presented to the interrupt controller. This is done to conserve the limited interrupt request inputs to the controller. The controller responds to the interrupt request by interrupting its host processor. However, rather than provide an interrupt acknowledgment signal to the peripheral controller that causes the peripheral controller to provide an interrupt vector, the interrupt controller provides a vector to the host processor that sends it to a generic interrupt service routine. The host processor relies on additional features implemented in "glue" logic to read the individual status of the interrupt request lines from the peripheral controller. This enables the interrupt routine to determine which interrupt request signals are active and choose which one to acknowledge. The acknowledgment is provided by glue logic that decodes the processors attempt to read from a certain address or addresses and activates a selected interrupt acknowledgment signal to the peripheral controller. The controller responds to the acknowledge signal by driving an interrupt vector onto the data bus. The host processor receives this vector as the data resulting from this glue logic-based read operation.
All these prior art solutions have involved signals that form a sort of "handshake" that must be supported by external dedicated hardware elements within the system, called controllers. Because of this hardware, interrupt-handling systems have been inherently inflexible and dedicated to one users system. It is desirable to have a flexible system that is software programmable such that many users can reconfigure one chip in order that the desired interrupt interface can be easily supported and reconfigured.